home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tech Arsenal 1
/
Tech Arsenal (Arsenal Computer).ISO
/
tek-04
/
share.zip
/
SHARE.INF
< prev
Wrap
Text File
|
1991-06-04
|
13KB
|
267 lines
Downloaded from Data-Link BBS in Baton Rouge, LA. 504-778-0015
and uploaded here by Bob Goodman...Bob<G>
DOS 4.01 SHARE Service Question
===============================
(This message I originally sent to a number of local BBS's,
which I have now slightly edited for clarity.
-Richard Fink 05-Mar-1990)
From: RICHARD FINK
To: ALL
Subject: DOS 4.01 SHARE Service Question
Do you remember my 9/10/89 question on this BBS regarding SHARE ?
Here is the original question followed by what I found out...
Tech Question regarding: DOS 4.01 SHARE
I know the purpose of SHARE in multi-user, multi-tasking and
network environments. But MS-DOS 4.01 seems to feel that SHARE
must be loaded just because a Large-Partition is defined. It
may be loaded either via the INSTALL command in the CONFIG.SYS
file or as a TSR in the AUTOEXEC.BAT file. But if you have a
DOS partition over 32 MB's and you don't install SHARE you
generate a DOS "WARNING....." message. DOS even goes so far
that if you have not installed SHARE it will search the root
directory for it and then AUTO-LOAD it !! Now THAT is a real
first ! Why...
I ran without it for months on a 100MB partition with absolutely
no problem. Then I got afraid of that constant boot-up warning
and put it back in my CONFIG file. Of course it is a pain at times
because it can interfere with reasonable desired file access-
such as backing up a file that has not been opened with the proper
Shared Read access by the owning TSR program. Not that you want to
actually back that file up but that it causes an error msg and
requires an operator response to continue. That's all fine for
the original intended purpose of SHARE but now what does it do for
partitions over 32 MB that is not needed in <32 MB partitions ?
Anybody know ?
Remember it's NOT required to operate with Large Partitions. I've
run for months without it... what was I missing ?
-Ric
-----------------------------------
Well like so many I made the trek to COMDEX a few weeks ago and
gave some effort to finding the answer to this profound question
of life and the need to SHARE. Microsoft didn't know the answer.
IBM was staffed by a techie who said "I really don't know the
answer to that, I just include it too." So I insisted and persisted
and made many at the IBM stand feel increasingly squirmy as nobody
knew the answer. How stupid they must have felt that somebody
was here asking a dumb DOS question when "we" all knew it no longer
mattered... that OS/2 was now the Real Thing.
THEN one day they gave a freebie day at COMDEX to an original DOS
programmer who worked on DOS 4.01 ! He quietly and completely
explained the answer... It's VERY interesting.
~~~~
If you use "modern" programs all the time, you may have
never run into problems using Large-Partitions (over 32MB)
without SHARE loaded. But beware...
The deal is that the old file FCB's cannot hold pointer
information in it's "reserved fields", on files that are
located on disk locations past 32MB's. When used in a
Large-Partition environment, FCB's can be okay as long as
the file is physically WITHIN the 32MB range of the partition.
However if part of the file is past the 32MB range, say in
the 38th megabyte area of the partition, the FCB doesn't
chuck-up or give an error, it just rolls the pointer value
over, thru zero, and gives DOS a new garbage value as an
internal disk pointer. The next disk read gives junk to
your program, the next disk write corrupts your disk.
It's Great Fun.
The reason SHARE is the solution is because it was already
doing the required fix for a different reason in small
partitions. To give file sharing protection in multi-user
environments SHARE would make a copy of a program's FCB in
a new local copy within SHARE and perform the file open from
SHARE's copy of the FCB. In so doing, it technically owned
the file and could effectively perform traffic-cop duty
regarding multi-access activity on the file.
Since old programs using hard coded FCB's had to be given a
way to run in Large-Partitions something had to be done to
the FCB disk pointer problem. The solution was to copy the
original FCB from within the program to a new "extended" format
of the FCB that would be in control by the operating system.
The extended form of the FCB with larger fields would be able
to support Large-Partitions, and any other extensions in the
future.
This FCB copy capability was already in existence in the
current SHARE facility. SHARE was just upgraded to not just
copy the FCB into it's own area for file access control but to
copy it into an extended FCB format, when applicable, for
Large-Partition access.
As nobody knows the internal code of the program's they run
everyday, you can never be positive if a program is using File
Handles via Extended File IO or old FCB's. (Actually, if you
can specify a path, it's 99.44% likely to be extended file IO
using a File Handle.) Since the use of FCB's in Large-partitions,
when accessing the disk area past 32 MB will corrupt the poor
user's disk, IBM said: "this is serious", and even forced the
bootup process to automatically search for SHARE in the root
directory if it had not been explicitly loaded in the config file.
Ahhhh.... and that explains why such "modern" people as myself
who had used only "modern" programs with File Handles (no FCB's)
never had any problems.
Right. But not completely safe.
Just lucky. The reason SHARE is an ABSOLUTE NECESSITY in systems
using Large-Partitions is this:
My IBM DOS programmer says that even today DOS itself still
uses some old FCB's internally for some unspecified internal
disk functions !
God help us, Microsoft sure didn't.
DOS still runs some original DOS 1.1 file access code that
REQUIRES SHARE in order not to, on some day, wipe out your
hard disk !!!
So if you're getting the SHARE WARNING at bootup friends, stick
it back in your config file, or just put it in the root directory
of you're C drive, and just eat the bytes it takes in memory...
Fact is, we've got no choice.
-Ric
-------------------------------------------------------------------
Copyright (C) 1990 RainTree Computer Systems.
Permission granted to electronically distribute in unmodified form.
Permission granted to publish with the requirement that a copy of
the final publication be sent to the holder of the copyright:
RainTree Computer Systems
P.O Box 2339
Mill Valley, CA 94941
===================================================================
P.S. DOS 4 will load SHARE automatically in the following cases:
1) if SHARE.EXE is in the same directory as specified for
COMMAND.COM in the SHELL= line in the CONFIG.SYS.
For example, if you put all of your DOS files in the
C:\DOS directory, then the following line in CONFIG.SYS
will allow DOS 4 to load SHARE automatically:
SHELL=C:\DOS\COMMAND.COM /P /E:512
or 2) if SHELL= is not specified in the CONFIG.SYS and SHARE.EXE
is in the root directory.
-----------------------------------------------------------------------
Addendum:
-----------------------------------------------------------------------
IBM PC RoundTable
Category 5, Topic 17
Message 1 Wed Nov 14, 1990
S.LUPPESCU (Forwarded)
This is a continuation of the topic summary: I didn't get the message when I
put SHARE.COM in the root directory where DOS could find it when I booted up,
and didn't get the message any more, but I couldn't detect any change in the
behavior of the computer except for the fact that SHARE was eating up about 7K
of memory. Does anyone know what SHARE does, why it is necessary, if it is OK
not to load it and save 7K? Thanks.
----------
IBM PC RoundTable
Category 5, Topic 17
Message 5 Sun Nov 18, 1990
C.JONES13 [Craig] at 01:21 PST
S.LUPPESCU,
The one thing that that zip file doesn't cover is that there is a difference
between explicitly loading SHARE (either via CONFIG.SYS or AUTOEXEC.BAT) and
letting DOS load it automatically (as you are doing). When you explicitly load
SHARE, 3 (or is it 4?) functions are invoked: File locking (sharing), support
for partitions greater than 32MB, and prevention of switching floppies with
open files. When DOS loads SHARE by itself, then only one of these functions
is actually invoked (>32MB support).
I run many programs that don't bother closing files on the floppy. So, it's
important to me that SHARE not check for that. Therefore, I let DOS load SHARE
by itself. Unfortunately, I also occasionally need to run Paradox in 2
DesqView windows at the same time--to test network applications, so file
locking would be nice. (Can you say "damned if you do, damned if you don't?")
At least, it turns out that even after DOS loads SHARE automatically (with the
one function invoked), you can turn on the rest of the functions by loading
SHARE (again) as a command.
8---m Craig 8---m 8---m
----------
IBM PC RoundTable
Category 5, Topic 17
Message 6 Sun Nov 18, 1990
NJUDELL [Neil] at 16:16 EST
Craig, there is an undocumented feature in share. If you load it explicitly
via install, you can disable the file sharing features by entering the command
share/nc, and then re-enable it via the command share. Neat, eh?
----------
IBM PC RoundTable
Category 5, Topic 17
Message 7 Mon Nov 19, 1990
C.JONES13 [Craig] at 23:28 PST
Neil,
How's that again? As I read you, I would first install SHARE explicitly via
CONFIG.SYS (INSTALL=SHARE.COM). This turns on all of the functions of SHARE.
Then, whenever I want to turn off the file sharing, I'd issue:
SHARE /NC
To turn it back on:
SHARE
Questions: (1) Will this also work if SHARE is installed via AUTOEXEC.BAT?
(2) How about if via LOADHI (DesqView)? (3) Does it also turn off diskette
change detection? (4) What does /NC stand for?
Thank You,
8---m Craig 8---m 8---m
----------
IBM PC RoundTable
Category 5, Topic 17
Message 8 Tue Nov 20, 1990
NJUDELL [Neil] at 08:27 EST
Craig, I have determined this experimentally. In my config.sys, I install
SHARE.EXE (NOTE: NOT share.com - I have not heard of share.com) in high
memory under QEMM via install=loadhi..., and then in the autoexec.bat turn off
file sharing via share/nc. I then can re-enable file sharing via share. In
this manner, all my FCB-based software such as SideKick+ works just fine and
dandy, and I don't end up with share violations. It appears to have no effect
on the change line for the floppy drives, which works just fine. I have used
this for both MS-DOS4.0 and MS-DOS4.01 large partitions. The /NC switch is,
of course, undocumented, like many (most?) of the useful things Microsoft
does. Experimentally, the /NC switch is what DOS does if you allow it to
autoload share (meaning that it is in the root directory of the boot drive, or
the drive/path where the SHELL is located). However, share does not appear to
recognize the /NC switch if it is applied in the INSTALL= statement, and so I
apply the switch after the INSTALL= by putting c:\share /NC into my
autoexec.bat. Using loadhi /TSR in the config.sys causes about 90 bytes or so
of low RAM to be used up. If you want to avoid even THAT low amount of low
RAM usage, and you don't mind seeing a warning message, you can eliminate the
/TSR from the INSTALL=loadhi... line, or you can move share.exe out from both
the root and the directory where your SHELL is located, and simply install it
from the autoexec.bat, using loadhi and the /NC switch.
----------